Amazon SQSキューにメッセージが配信されるたびにEメール通知がくるアーキテクチャをまとめてみた

Amazon SQSキューへメッセージが配信されるたびにEメール通知したい

おのやんです。

みなさん、Amazon SQS（以下、SQS）キューにメッセージが追加されるたびにEメール通知されるようにしたいと思ったことはありませんか？私はあります。

例えば、AWS Lambda（以下、Lambda）の非同期実行が失敗した時用のデッドレターキュー（以下、DLQ）を設定している場合、DLQへのメッセージ配信時の通知をLambdaエラー通知として代用するケースが多々あります。そういった場合にどのAWSサービスを利用すれば可能なのか検証しましたので、今回2通りほど紹介します。

Amazon CloudWatch アラーム経由でEメール通知

ひとつめはAmazon CloudWatch（以下、CloudWatch） アラーム経由でEメール通知するアーキテクチャです。SQSキューに配信されたメッセージ数を取得できるCloudWatch メトリクスがNumberOfMessagesSentですので、こちらに閾値を設定してアラームを出す形になります。

NumberOfMessagesSentについては、公式ドキュメントにも記載があります。

https://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html

今回は検証のために、必ずエラーが出るLambda関数を用意して、こちらにDLQとしてSQSを設定します。

import json

def lambda_handler(event, context):

    # raise error 
    raise ValueError("エラー!")

    # TODO implement
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

CloudWatchアラームに関する設定は以下のとおりです。こちらにAmazon SNSを設定して、アラームが発火されるたびにEメール通知が行くようにします。

こちらを設定して、例として15分おきにLambda関数を実行させるとします。Lambda関数は今回は必ず失敗するよう設定されているので、15分おきにDLQにメッセージが配信されます。このメッセージ配信イベントをNumberOfMessagesSentメトリクスから取得して、CloudWatchアラームが発火されます。

正常にSNSが設定されていれば、Eメール通知もされます。

Amazon EventBridge Pipes 経由でEメール通知

ふたつめは、Amazon EventBridge（以下、EventBridge） Pipes 経由でEメール通知するアーキテクチャです。SQSキューに配信されたメッセージをポーリングして、EventBridgeのターゲットとしてSNSを設定してEメール通知を行います。

SQSキューをEventBridge Pipesのソースとして設定できる旨は、こちらのドキュメントにも書いてあります。

https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-pipes-sqs.html

また、EventBridge PipesのターゲットとしてSNSトピックを指定できる旨は、こちらのドキュメントに記載されています。

https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-pipes-event-target.html

Lambdaは上記と同様にエラーを吐くものに設定しておいて、15分間隔で実行させます。15分おきに非同期実行がエラーになりDLQにメッセージが配信されるため、このメッセージをポーリングしてEメールが通知されます。

2つのアーキテクチャの違い

両者を比較してみて感じられる違いとしては、 Eメール通知後にSQS内のメッセージが削除されるかどうか と Eメール通知の内容 です。

Eメール通知後にSQS内のメッセージが削除されるかどうか

CloudWatch アラームを経由した場合、SQS内のメッセージは削除されません。そのため、連続してLambdaがエラーを起こした場合、SQS内にメッセージが溜まり続けます。Eメール通知と並行してLambda非同期実行時のエラー処理を自動化したい、といった要件ですと、CloudWatchアラームの採用が候補に上がります。一方で、CloudWatch アラームの条件式やしきい値など、管理するパラメータが増える側面もあります。

一方、EventBridge Pipesを経由した場合、SQS内のメッセージは削除されます（参考）。DLQに溜めたエラーメッセージを消費して通知するため、Lambda非同期実行時のエラー処理を手動で実施するような場合は、こちらも選択肢に入ってきます。CloudWatch アラームを運用する必要もなくなります。

Eメール通知の内容

個人の主観の話になりますが、CloudWatchアラームを経由した場合、Eメール通知の文面の内容が比較的わかりやすいと感じます。発火したCloudWatch アラーム名も題名に書いてあるため、ひと目見て通知内容を把握しやすいのはこちらの方では、と思います。

一方で、EventBridge Pipesを経由した場合、Lambdaなどでメール本文の編集を行なっていないと、SQSメッセージがそのままEメール本文に掲載されます。一般的に、こちらからエラーの内容を把握するのは少々時間がかかるのではないでしょうか？

EventBridge Pipe上の設定で、Eメール本文のメッセージをLambdaなどで加工できますが、実際に採用する場合は加工部分の運用も考える必要がありそうです。

2つのアーキテクチャは、どこを運用するかで選ぶと良さそう

以上を踏まえて、CloudWatch アラームを経由する場合はCloudWatch アラームの運用を、EventBdirge Pipes を経由する場合はメール本文の運用を考える必要がありそうです。

SQSキューのEメール通知を考えている方は、こちらの記事が参考になれば幸いです。では！